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REMARKS 

Claims 14-20 and 22-27 were rejected pursuant to 34 U.S.C. §101 as being directed to 
non-statutory subject matter. Both claims 14 and 22 are directed to statutory subject matter. 
The transformation of data representing a patient into an image is directed to statutory subject 
matter (See In re Bilski ). 

In the Office Action, the Examiner again rejected claims 1, 3, 5, 11-14, 16, 18, and 24- 
26 pursuant to 35 U.S.C. §103 (a) as unpatentable over Halmann, et al. (US 6,526,163) in view 
of Seiler, et al. (EP 1,093,085). Claim 2 was rejected pursuant to 35 U.S.C. § 103(a) as 
unpatentable over Halmann, et al. in view of Seiler and further in view of Zar (A Scan 
Conversion Engine...). Claims 4 and 17 were rejected pursuant to 35 U.S.C. §103(a) as 
unpatentable over Halmann, et al. in view of Seiler, et al and Hossack, et al. (US 6,352,51 1). 
Claims 6 and 19 were rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et 
al. in view of Seiler, et al. and Okerlund, et al. (US 6,690,371). Claims 7 and 20 were rejected 
pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. in view of Seiler, et al. and 
Drebin, et al. (US 4,835,712). Claims 9 and 22 were rejected pursuant to 35 U.S.C. § 103(a) as 
unpatentable over Halmann, et al. in view of Seiler, et al. and Swerdloff (US 5,483,567). Claim 
15 was rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. in view of 
Seiler, et al. and Fattah (US 7,274,325). Claim 27 was rejected pursuant to 35 U.S.C. § 103(a) 
as unpatentable over Halmann, et al. in view of Seiler, et al. and Edic, et al. (US 2004/0136490). 

Claim 8 was allowed. Claims 10 and 21 were objected to as being allowable if amended 
into independent form. 

Applicants respectfully request reconsideration of the rejections of claims 1-7, 9, 1 1-20, 
and 22-27, including independent claims 1 and 14. 

Independent claim 1 recites a processor operable to identify acquired ultrasound data as 
a function of the values where a look-up table has the values corresponding to a spatial 
conversion from the display format to the acquisition format. 

Halmann, et al. do not disclose this limitation. Halmann, et al. note that a CPU 
generates the scan converter tables necessary to convert scanned data from the polar coordinate 
system to the Cartesian coordinate system where the tables are dependent on the mode of 
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operation (col. 7, lines 54-59). Scan conversion is performed with interpolation and the like 
(col. 8, line 53-col. 9, line 4). Halmann, et al. do not provide further details for the tables, but 
indicate that the tables convert the data. Halmann, et al. do not use values of the table to 
identify ultrasound data. There is no teaching that acquired ultrasound data is identified as a 
function of the values of the look-up table. 

The tables of Halmann, et al. would be used by applying each ultrasound datum to the 
table. The table then provides for conversion of the ultrasound data. Each datum is converted, 
so the identity of a given ultrasound datum is not needed. The original data is converted 
regardless of identity. 

Claim 1 recites that the table has values corresponding to a spatial conversion from the 
display format to the acquisition format. Halmann, et al. convert polar coordinates into 
Cartesian coordinates (col. 7, lines 55-57; and col. 8, lines 64-65), not a look-up table used 
for the inverse conversion of Cartesian coordinates to the polar coordinates. 

The Examiner alleges that, since the scan conversion is converting the polar scanned 
data to display values, it is identifying the polar data as a function of the Cartesian values, 
and alleges that the look-up table is reversible. However, Halmann, et al. do not disclose the 
structure of the lookup table. The lookup table, to be used for scan conversion, likely has 
interpolation values (not a Cartesian coordinate) given an input Polar coordinate. The 
interpolation values are then applied to the data for that Polar coordinate to weight the data 
and create Cartesian data. The table is likely for interpolation values for the actual 
conversion of data at particular coordinates, so would not have a Cartesian coordinate output 
given a polar coordinate input. 

Even if the table is addressed by scan coordinates, to use inversely, the specific 
interpolation values, not a Cartesian coordinate, would be needed to address the table. For 
example, the table would be addressed by polar coordinate to output interpolation weights 
(e.g., 0.93). These interpolation values correspond to spatial relationships, so may be 
identical for different locations. Using the table in reverse would result in multiple polar 
coordinates given an input interpolation value. 

Even if reversible, Halmann, et al. convert polar coordinate data to Cartesian coordinate 
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data. There is no reason to identify polar coordinate data from or starting with a Cartesian 
coordinate. The process flows by providing polar coordinate data. The polar coordinate data is 
then interpolated (weighted and summed) to represent data at a Cartesian coordinate. The 
location of the Cartesian coordinate does not need to be known before hand. The available 
polar coordinate data is converted. An inverse lookup would not occur. 

Independent claim 1 further recites that the processor is operable to avoid scan- 
conversion of volume data that does not contribute to a final volume rendered image, the 
identifying corresponding to identifying for display format coordinates associated with 
visible voxels of the final volume rendered image. Halmann, et al. and Seiler, et al. do not 
disclose these limitations. 

Halmann, et al. simply scan converts all the incoming polar coordinate values for 
imaging. All the scan conversion tasks are completed so that a 2D image is generated (col. 9, 
lines 4-13). Volume rendering is performed from the 2D images (col. 5, lines 34-40). 
Halmann, et al. rely on polar coordinate to Cartesian coordinate scan conversion, converting 
all of the frames of data to provide 2D images, and then perform volume rendering from the 
2D images. Halmann, et al. do not operate scan conversion as a function of the volume 
rendering, so do not avoid scan-conversion of volume data that does not contribute to a final 
volume rendered image, the identifying corresponding to identifying for display format 
coordinates associated with visible voxels of the final volume rendered image. 

The Examiner takes a mere general statement about generating scan conversion tables 
and alleges obviousness of the claim, indicating hindsight reasoning. 

Seiler, et al. also do not avoid scan conversion. As known in the art and recited in the 
claim, scan conversion corresponds to a spatial conversion from a two-dimensional 
acquisition format to a two-dimension display format. Seiler, et al. do not disclose scan 
conversion. Instead, a volume of data is the starting point (paragraphs 2, 8, and 34-35). 
Volume sections are reviewed to avoid transfer for 3D rendering of 3D voxels. Seiler, et al. 
start with volume data and avoid 3D rendering of voxels, so do not avoid scan conversion. 

A person of ordinary skill in the art would not have used the avoidance of transfer of 
voxels with the scan conversion of Halmann, et al. Seiler, et al. use as input a volume set of 
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data. Halmann, et al. generates 2D images by scan conversion (col. 9, lines 4-13). A 
collection of the scan converted images are used to form a volume data set for rendering, 
(col. 5, lines 33-40). Halmann, et al. treat scan conversion and rendering separately. A 
person of ordinary skill in the art would have used the voxel control for rendering of Seiler, 
et al. with the rendering of Halmann, et al., not the different scan conversion process. 

A person of ordinary skill in the art would not have used the voxel transfer avoidance 
of Seiler, et al. with the scan conversion of Halmann, et al. for another reason - failure to 
enable. Seiler, et al. rely on the data in a volume arrangement or volume sections extracted 
from the volume data to determine which voxels not to use. The view direction, size of the 
volume, equations for cut and crop planes in the volume, and bounding boxes are volume 
related factors used to select voxels (paragraphs 77 and 78). The volume data set is needed 
to even determine these factors. As of the scan conversion of Halmann, et al., the volume 
data set is not yet created. A person of ordinary skill in the art would not know how to use 
voxel selection in the scan conversion process as Seiler, et al. provide a process for a 
rendering pipeline with the volume data as a starting point. 

Using 3D rendering voxel transfer avoidance of Seiler, et al. in the scan conversion of 
Halmann, et al. is using improper hindsight reasoning. 

Independent claim 14 is allowable for similar reasons as claim 1. 

Dependent claims 2-7, 9, 1 1-13, 15-20, 22, and 24-27 depend from claims 1 and 14, and 
are allowable for the same reasons as the corresponding base claim. Further limitations 
patentably distinguish from the cited references. 

Claims 3 and 16 recite determining the display coordinates of interest and identifying 
the acquired ultrasound data by input of the display coordinates into the look-up table. The 
Examiner cites to col. 8, lines 4-9 of Halmann, et al. Halmann, et al. may locate an area of 
interest, but the area is not used to identify acquired data by input into the look-up table. 
Identifying all ultrasound data is not using the area to identify data. 

Claims 5 and 18 recite the display coordinates of interest input to the look-up table 
being coordinates for a plurality of rays through the volume. Halmann, et al. disclose a 
raycasting/volume rendering module 201, but this module 201 is not shown to work with the 
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tables of the separate scan conversion module 207. The Examiner alleges there is no way to 
render an image if the original coordinates are polar, but that is not true. The rendering can 
account for any coordinate system. The rendering, rather than scan conversion, may provide 
data for each pixel based on ray casting, regardless of the format of the input data. Halmann, 
et al. do not put ray coordinates into a scan conversion look-up table. 

Claim 1 1 recites a graphics processing unit (GPU). GPUs are typically used in 3D 
rendering. As noted by the Examiner, GPUs are well known yet Halmann, et al. use CPUs. 
The nature of the scan conversion process is such that GPUs are not used. It would not have 
been obvious to use a GPU in scan conversion. 

Claim 26 recites generating a two-dimensional look-up table with acquisition format 
coordinates for each coordinate of a Cartesian volume. Halmann, et al. treat volume 
rendering separately from scan conversion. There is no disclosure of a LUT for coordinates 
of a Cartesian volume. The Examiner alleges there is no way to render an image if the 
original coordinates are polar, but that is not true. The rendering can account for any 
coordinate system. Also, the process of Halmann, et al. may be used - convert from Polar to 
Cartesian. The image is rendered from a volume of Cartesian data, so a reverse table would 
not be used. 

Claim 2 recites values of the look-up table being Polar coordinates where the look-up 
table is indexed by integer Cartesian coordinates. Halmann, et al. do not disclose coordinate 
values in the look-up table, and do not disclose Polar coordinates as the values of the look-up 
table indexed by Cartesian coordinates. Col. 7, lines 50-58 show conversion of scanned data 
to a different coordinate system, not coordinate values. Zar discloses bilinear interpolation 
of ultrasound data, not a look-up table of coordinates. 

Claim 4 recites the processor operable to determine a plane through a volume as the 
display coordinates where the display coordinates are input to the look-up table. Hossack, et 
al. show arbitrary plane display for a volume, but do not use the coordinates of the plane as 
an input to the look-up table. Halmann, et al. treat volume rendering and scan conversion 
separately, so do not use coordinates of a plane in a volume as input to the scan conversion 
table. The form of conversion used would be the form taught by Halmann, et al, not a 
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reverse conversion that also intermixes the separate rendering process. Claim 17 is allowable 
for similar reasons. 

Claims 6 and 19 are allowable for the same reasons as claim 5. Claims 6 and 19 are 
also allowable because a person of ordinary skill in the art would not have used the cited 
rendering of Okerlund, et al. with Halmann, et al. The cited section for alpha blending of 
Okerlund, et al. teach a hardware based RGB A approach (col. 7, lines 4-19). Alpha blending 
is provided using hardware acceleration. However, Halmann, et al. desire versatility so use 
programmable CPUs to avoid hardware specialization (col. 2, lines 42-52). A person of 
ordinary skill in the art would not have used the hardware acceleration based alpha blending 
of Okerlund, et al. with the general programming approach of Halmann, et al. The Examiner 
alleges that the methods are compatible. However, CPU based rendering and hardware 
acceleration are alternatives being compatible is not the test. Being compatible is not the 
test. A person of ordinary skill would not have used rendering in scan conversion. 

Claim 12 recites a flag, and an integer sum. As noted in the specification, an integer 
sum allows indication of spatial relationship relative to other table entries. Halmann, et al. 
do not suggest any format for the look-up table, and certainly do not disclose an integer sum, 
a flag or fixed-point values. These values are chosen to allow table based identification of 
data rather than scan conversion of the data. Selective scan conversion of only the samples 
that contribute to the rendering result without having to scan convert occluded data is 
provided by the recited table variables. A person of ordinary skill in the art would not have 
provided the listed classes as a mere design choice. The flag and integer sum would not have 
been considered as there is no reason for them in Halmann, et al. Just being well knowN is 
insufficient. 
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CONCLUSION : 

Applicants respectfully submit that all of the pending claims are in condition for 
allowance and seeks early allowance thereof. 



PLEASE MAIL CORRESPONDENCE TO: Respectfully submitted, 

/RosaS. Kim/ 



Siemens Corporation 

Customer No. 28524 

Attn: Elsa Keller, Legal Administrator 

170 Wood Avenue South 

Iselin, NJ 08830 



Rosa S. Kim, Reg. No. 39,728 
Attorney(s) for Applicant(s) 
Telephone: 650-694-5330 
Date: March 17. 2009 
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